1. Fields of the Invention
The present invention generally relates to debugging an error in a program. More particularly, the present invention relates to generating and storing trace information (e.g., parameters passed to a called subroutine, return values of a subroutine, trace data) of a program to debug an error in the program.
2. Description of the Prior Art
Application tracing is important to provide trace information when a program has failed. For example, the application tracing has following requirements;                trace as much usefull detail as possible;        do not store too much information;        trace as little information as possible that is unrelated to an event (e.g., a failure, a defect, an error, a warning) to diagnose;        
Currently, a lot of large applications use proprietary tracing software, but the tracing software is often based on common systems. For example, a programming language Java comes with a built-in tracing application (e.g., java.util.logging (also known as JSR 47)).
When the application tracing detects an event (e.g., an error, a failure, or a problem), traditional solutions turn up a tracing level (e.g., a tracing level OFF indicates gathering no information to trace out; a tracing level LOW indicates gathering a very high level view information; a tracing level HIGH indicates gathering large amounts of debug information, but may affect a system performance due to large amounts of I/O
operation and consume lots of storage space) for the detected event to gather information necessary to recreate the event.                These traditional solutions have two disadvantages:        The traditional solutions require the event (e.g., an error, a failure, or a problem) to be recreated, so that a sufficient amount of data is collected. However, recreating the event is not always possible in a customer environment.        The traditional solutions gather all information traced from where an event occurred.        However, the gathered information may be a substantial amount, causing a difficulty in analyzing the gathered information by a user (e.g., a product developer, an application developer). Furthermore, gathering information impacts a system performance by increasing resource usages (e.g., a memory usages increase, a CPU usage increase, a hard disk usage increase).        
In traditional solutions, circular buffers are often used to store a limited amount of detailed trace data (e.g., brief summary of recently executed operation). When an event occurs, the detailed trace data in the circular buffer is transferred to a secondary storage device (e.g., a disk) for a later analysis. However, using the circular buffer has limitations:                The circular buffer will often wrap around, loosing important information (e.g., initial configuration and setup information)        The circular buffer may be full of lots of detailed data. However, most of the data in the circular buffer may be unrelated information to an event (e.g., an error, a defect, a failure).        
Alexander, III et al (U.S. Pat. No. 6,604,210 B1) discloses a method and system for detecting and recovering from errors in trace data. The trace data records selected events for executing routines and the routines corresponding to the events are represented as one or more nodes in a tree structure. The events may be entries and exits to executing methods.
A non-patent literature entitled “Trace Cache Sampling Filter”, Michael Behar et al., Proceedings of the 14th International Conference on Parallel Architectures and Compilation Techniques (PACT'05), 2005 IEEE, IEEE Computer Society, discloses a technique for efficient usage of small trace caches. A trace cache can significantly increase the performance of wide out-of-order processors, but to be effective, the size of the trace cache should be large.
It would be desirable to provide a system and method for maintaining detailed trace information relevant to a current operation being processed in a program.